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ABSTRACT 

The Network Command Processing System (NCPS) developed for the National Aeronautics and 
Space Administration (NASA) Ground Network (GN) stations by the AlliedSignal Technical 
Services, Corporation (ATSC) is a spacecraft command system utilizing a MULTIBUS 1/68030 
microprocessor. This system was developed and implemented at ground stations worldwide to 
provide a Project Operations Control Center (POCC) with command capability for support of 
spacecraft operations such as the LANDSAT, Shuttle, Tracking and Data Relay Satellite and 
Nimbus-7. The NCPS consolidates multiple modulation schemes for supporting various 
manned/unmanned orbital platforms. The NCPS interacts with the POCC and a local operator to 
process configuration requests, generate modulated uplink sequences, and inform users of the 
ground command link status. This paper presents the system functional description, hardware 
description and the software design. 


BACKGROUND 

In 1987, ATSC was directed by the NASA to design a replacement spacecraft command system 
for the early 1970's vintage Spacecraft Command Encoder (SCE). The project goal was to 
devise a system that would utilize state-of-the-art hardware and software, provide on-site fault 
isolation and eliminate cumbersome analog alignment requirements. The initial design study 
determined that there would be a significant software cost benefit in modeling the system after 
the NASA Telemetry and Communications Data System (TCDS). The TCDS is a telemetry data 
processing system developed in the mid 1980s which utilized distributed processing techniques 
and was the replacement for outdated decommutators and data system computers on the NASA 
GN. Due to the differences in functionality between the TCDS and NCPS, only portions of the 
hardware components could be re-used. However, the basic hardware system architecture and 
the device driver software for these components could be implemented with minimal 
modification. 
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SYSTEM FUNCTIONAL DESCRIPTION 


The NCPS provides the POCC and/or a local operator with the capability to command a 
spacecraft and to monitor the command system status. Figure 1 is a simplified functional block 
diagram of the system. There are three command modes: throughput, local, and hardline. Each 
mode has a different source of data. In throughput mode, data is received for uplink via the 
NASA Communication (NASCOM) Data Link in 4800 bit blocks. In local mode, data prestored 
in co mman d pools is used. Each command pool may contain several spacecraft commands that 
are between 16 to 2000 bits in length. In hardline mode, serial command data is received via a 
connector on the rear of the NCPS and sent directly to the uplinking hardware with little 
intervention from the software. 

The NCPS operator uses a menu interface to select one of the three commanding modes. Once a 
commanding mode has been selected, the operator enters a spacecraft identification (SID) code 
and a file designator character code. These two codes are used to retrieve the selected spacecraft 
attribute file from the hard disk which contains default commanding parameters. The NCPS 
loads this file into its database memory and enters a prepass state. The current configuration 
attributes, status information and menu selection items for modifying spacecraft attributes, is 
shown on the video terminal. Each commanding mode has two operating states: prepass and 
pass. Prepass is the state of operation prior to uplink. In this state, the operator can modify and 
override certain spacecraft attributes. Pass is the state of operation where data is uplinked to the 
spacecraft and is entered via an operator menu selection when the system is in the prepass state. 
In the pass state, some attributes that do not affect command uplink can be modified, including 
selecting and uplinking an idle data sequence between commands. 

In the throughput commanding mode, three options are available: uplink immediate, buffered 
up link, and rate adjust. The uplink immediate option permits the command data to be 
transmitted as soon as it is received. The buffered uplink option accumulates one command data 
block before beginning command transmission to the spacecraft. Buffering allows for 
compensation of irregularities in the data arrival time and a precisely metered continuous data 
flow to be generated. When the received average data rate is different than the precise uplink 
command data rate, a circumstance may arise in which the buffered data may be consumed or an 
excessive amount may accumulate. To diminish this possibility, a rate adjustment feature has 
been incorporated in which the uplink command rate is varied to match the average command 
rate received from the commanding source. If the number of blocks begins to decline, the 
software retards the uplink rate. If the number of blocks drops to zero, the software notifies the 
operator that an underflow has occurred. The software will also advance the uplink rate when 
the number of buffered blocks grows towards a predetermined maximum. The software notifies 
the operator that an overflow has occurred if the number of buffered blocks exceeds the 
predetermined maximum. 

In the local commanding mode, the operator selects commands to be uplinked from a prestored 
command file by specifying a command "mark" number. This command will be uplinked 
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according to the parameters in the selected spacecraft attribute file upon release by the NCPS 
local operator. 

In the hardline commanding mode, the operator configures the NCPS for the selected spacecraft 
and enters the pass state. Any data received through the hardline connection is uplinked 
according to the parameters in the selected spacecraft attribute file. This mode is used at 
locations where serial command data can be received directly from a POCC command generator. 
This mode is primarily used for testing a spacecraft shortly before launch. 

The output of the NCPS is a Phase Shift Keyed (PSK) modulated subcarrier or a modulated 
squarewave for the scientific spacecraft and the shuttle, respectively which is routed to the 
transmitting system exciter. The subcarrier frequency and the data rate used to modulate the 
subcarrier are determined by the selected spacecraft attribute file. 

The NCPS system status is reported using Site Status Messages (SSM) and command echo 
NASCOM blocks. Options to enable or disable both the SSM and echo block functions are 
available from the operator menu. 

SSM blocks are generated and transmitted to the project specified by the status destination code 
at the rate of one block per second in both the prepass and pass state. SSMs contain information 
about the status of the NCPS including information about the site, identification of the spacecraft 
being commanded and the status of the uplink process. 

Echo blocks contain the data that was uplinked and are transmitted to the project specified by the 
echo destination code. There are two types of echo blocks: asynchronous and synchronous. 
Asynchronous blocks contain the image of the uplink data as received from the verification 
receiver which samples the uplink RF output. Synchronous blocks are the NASCOM blocks that 
were received from a project using the source and destination codes interchanged and 
transmitted back to the originating project. 


HARDWARE DESCRIPTION 

The NCPS is housed in a single 19-in. standard NASA equipment rack. The units mounted in 
the rack include a 140 Mbyte hard disk drive, a 5V4-inch floppy disk drive, a streaming tape 
unit, a 14-in. color graphics terminal, a standard 101 keyboard and the NCPS chassis. The 
functional and ergonomic lay-out provides the operators with easy access to the system. Figure 
2 illustrates the NCPS rack elevation layout. 

Chassis 

The NCPS chassis uses a MULTIBUS I architecture with a 20-slot card cage to accommodate 
the six PC cards and to provide for expansion or modification. Of the six board assemblies, one 
is a commercially available computer board and five are special purpose custom designed boards 
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i.e. Serial Time Code Receiver board, Transmit/Receive board. External 5 MHz board, a PSK 
Modulation Board (PMB), and Shuttle Command Module (SCM). 

Computer Board 

The computer board utilizes a 68030 32-bit microprocessor with 4 Mbytes of RAM. This board 
performs the central control function of the NCPS. The system initialization instructions are 
stored in EPROM. The computer board also provides interfaces to disks, streaming tape, 
graphic video terminal and an external printer. 

Serial Time Code Receiver Board 

The Serial Time Code Receiver board was developed by NASA. The board decodes the 
received serial binary 1 (SB-1) time code which is a Manchester encoded RS-422 signal into 
parallel time with millisecond accuracy which the NCPS software inserts into the transmitted 
NASCOM 4800 bit block. The source of the SB-1 time code is the station master timing 
system. 

Transmit/Receive Board 

The Transmit/Receive (T/R) board was developed by ATSC for the TCDS and is used to 
interface with the NASCOM communication system. It provides the channel for processing a 
digital serial data stream of NASCOM blocks entering or leaving the NCPS. 

External 5 MHz Board 

The External 5 MHz board provides frequency synthesis by using a Phase-Locked Loop (PLL) 
technique. The purpose of the board is to generate a phase coherent 4.096 MHz signal from the 
station's 5 MHz signal. A monolithic PLL was used for fractional frequency synthesis in the 
External 5MHz board and consists of a Voltage Control Oscillator (VCO), phase comparator 
and low pass filter. The monolithic PLL was used in this application because of its low cost and 
high performance at frequencies below 50 MHz. 

A block diagram representation of the fractional frequency synthesizer is shown in Figure 3. 
The phase locked loop operates by producing an oscillator frequency to match the frequency of 
an input signal. In this locked condition any slight change in input frequency, f a , first appears as 
a change in phase between f a and the oscillator frequency, f c . The phase shift then acts as an 
error signal to change the oscillator's frequency to match the f a . 

Having a crystal-controlled VCO and phase- locked to the station's precise main timing system 
results in a long term stable clock. This procedure was incorporated in the hardware design to 
increase the stability of the modulated subcarrier. 
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PSK Modulation Board 


The PSK Modulation Board (PMB) is designed to provide command support for all subcarrier 
modulated compatible spacecraft. Control, setup, and ground command verification sequences 
are received via the Multibus interface. The command data to be uplinked is received from the 
CPU via the Multibus interface in all modes with the exception that in hardline mode it is 
received via a direct serial interface. 

The PMB is divided into three functional areas: Command Data Control (CDC), Subcarrier 
Modulation/Demodulation (SMD), and the Serial Data Interface (SDI). Figure 4 illustrates the 
PMB Functional Block Diagram. 

The CDC interface permits control and setup of the PMB by the CPU via the multibus interface. 
The PMB setup/control words, provided from the hard disk's spacecraft attribute files, select the 
subcarrier frequency, data (modulation) rate, data type encoding, command idle, modulating 
source, and command mode. 

The SMD process generates a composite modulated PSK waveform and utilizes a stable 
frequency source, rate multipliers, a sinusoidal look-up table, a digital-to-analog converter, and a 
single pole low-pass filter. The subcarrier rate multiplier along with the frequency reference, 
which can be from an on-board crystal or the External 5 MHz board, generates subcarrier 
samples at 256 times the selected subcarrier frequency. The subcarrier samples are the result of 
a phase counter addressing a sinusoidal look-up table, that is contained in PROM. The PROM 
contents are specified by the equation 

Dj * sin(2 * pi * K/256) 

where K represents the address of the subcarrier phase counter and Dj represents the sign of the 
data sequence. The active single pole low-pass filter eliminates the out of band harmonic power. 

The SDI interface is provided to permit the processing of a serial command sequence. When the 
serial data mode is selected on the PMB, the transition tracking loop is selected versus the 
reference 4.096 MHz. The transition tracking loop drives the subcarrier phase to provide proper 
alignment of the subcarrier transitions and the data symbols being transmitted. 

Shuttle Command Module 

The Shuttle Command Module (SCM) is designed to provide the NCPS with a shuttle orbiter 
ground-to-space command link. A series of control data directives are used by the NCPS host 
processor to communicate to the SCM. The control data directives include uplink configuration, 
modulation source and rate. 

The SCM can be configured to operate as both a voice-command multiplexer or as a throughput 
device. Figure 5 illustrates the SCM Functional Block Diagram. In a multiplexer configuration, 
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the SCM generates a multiplexed uplink sequence containing command patterns supplied by the 
selected source and overlays voice supplied from a local Delta Modulation Sub-system (DMS). 
The data sources in a multiplexer configuration are host, hardline, and local controller. As a 
throughput device, the selected source supplies the entire composite baseband uplink modulating 
sequence. The only valid data sources in die throughput configuration are host and hardline. In 
either configuration, multiplexer, or throughput, the composite baseband can be encoded with a 
rate 1/3 convolutional code with the following polynomial definitions: 

Gi=D 6 +D 1 * 3 +D 2 +D+1 ; G2=D 6 +D5+D 3 +D 2 +D+ 1 ; G3=D 6 +D 4 +D+1. 

In support of hardline, analog tape playback, and host throughput rate adjust uplink, the SCM 
employs a digital tracking loop with a maximum tracking bandwidth of 200 ppm. 

Peripheral 

An external serial line printer provides a hard copy of all NCPS activities and status information 
and is used primarily for historical data and as a troubleshooting aid. 


SOFTWARE DESCRIPTION 

The NCPS software development task began in 1987. The original software project included 
software to support a wide range of ground stations and spacecraft. However, several ground 
stations were closing and some spacecraft were becoming obsolete. The NCPS was required to 
support both the aging spacecraft, as well as, future spacecraft. A design approach to maintain 
an ever-changing system was needed. Other projects were also faced with application software 
that was developed and modified on a continuing basis. In order to optimize the generation and 
maintenance of those applications a distributed operating system and a multi-tasking executive 
(MX) were developed to support these projects. A paper "Distributed Operating System for 
NASA Ground Station" written by John Doyle in 1987 provides background for the software 
section of this paper[l]. 

NCPS Software Design Goals and Considerations 

The NCPS software design goal was to utilize as much of the in-house software and tools as 
possible without inhibiting the development and uniqueness of the NCPS application. Software 
design objectives described in the following paragraphs were considered during the design 
phase. 

1. A modular approach in software development, allowing for incremental source code revision, 

was needed to reassure the growth of the NCPS. In order to support future spacecraft, such as 

the Space Shuttle, hardware devices and software drivers would need to be added to the NCPS 

baseline without disrupting a current working system. 
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2. The design was based on reusable and replaceable modules. As tools and software 
components evolved they could be substituted for older and less efficient ones. Modules that 
were used in other systems, such as, the Transmit/Receive board and driver software could be 
incorporated into the NCPS without modification. 

3. A memory resident database containing information that could be accessed instandy was 
needed for updating status displays and the operator interface. 

4. Software and tools developed during the NCPS design phase were written in C using the 
UNIX operating system on a Heurikon computer. In order to reuse software, a similar 
development environment was selected for the NCPS. 

5. An objective to automate system documentation through the use of graphical representation 
was considered. An in-house software tool known as the Network Adaptive Schema for 
Modeling Asynchronous Computation (NASMAC) was developed for previous projects. This 
tool allowed for the specification of software systems using directed graphs, and the automatic 
transformation of such graphs into operational software. These graphs provided an overview of 
the application software without the knowledge of the underlying system. This tool was the 
foundation for the NCPS software. It provided application documentation in the form of 
directed graphs and a modular design for the software. 

6. At the time of the NCPS design, an operator interface was developed in-house. Batch files, 
prompts, sequenced commands and a command processor for the menus, along with the 
database, display formats and a display processor, facilitated an operator interface that could be 
custom designed on the fly. No recompilation of code was necessary. The system database 
could be instantly accessed and updated, providing up-to-date status information. 

The objectives that were formed proved to be advantageous in the growth of the NCPS and the 
support of future spacecraft. Operator interface software, in-house developed tools and device 
driver software could be reused while new components and modules could be added. 

NCPS Modular Software Design 

Once the decision to use a modular design approach and in-house developed software was made, 
focus was moved to the NCPS functionality and the software application. Figure 6 is a data flow 
diagram which depicts the NCPS application and the software components. Each node on the 
data flow diagram depicts a module in the NCPS application. The following is a description of 
each of the modules. 

1. Operator Interface: This module allows for a local operator to communicate with the NCPS 
system. Drivers to support terminal and printer devices, alarm functions which provide the 
operator with information about the state of the system, and the operator interface command and 
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display processors were reused from previous projects. New command files and ASCII display 
formats were created to support the NCPS specific menus. 

2. repeal Commanding and Utilities: Local Commanding software to support this module was 
written specifically for the NCPS. It included a means to create and update command pools, test 
files and attribute files. Attribute files are used to configure the NCPS in order to support a 
variety of stations and spacecraft. Run-time hard disk file system utilities, developed for 
previous projects, were incorporated into the NCPS. 

3. NASCOM Interface: The NASCOM interface consists of a driver to support the 
Transmit/Receive board that has been used in several projects. The code and hardware for this 
module was incorporated in the NCPS without modification. This board receives serial data 
from the NASCOM Data Link (NDL) and blocks it in the form of NASCOM blocks. It also 
extracts data from a NASCOM block and serially transfers it to the NDL. 

4. Throughput Commanding: Throughput commanding for the NCPS software performs 
verification of the blocks received from the NASCOM interface and passes it to the PSK 
Modulator/Demodulator (MOD/DEMOD) interface for uplink. All code for this module was 
written specifically for the NCPS. 

5. PSK MOD/nFMOf) Interface: The PSK MOD/DEMOD interface is device driver to support 
the PSK Modulation Board. It transfers forward and configuration data to the PSK board and 
receives echo and status information from the PSK board. 

6. ECHO/STATIJS Process: This module collects echo and status data and formats it into a 
NASCOM block. It creates a header based on information stored in the spacecraft attribute file. 

NCPS Space Shuttle Modification 

Because of the modular design of the system, the NCPS was able to incorporate software to 
support the Space Shuttle in approximately 6 person-months without disrupting the current 
working system. Modification to the NCPS software included new command files and display 
formats to support a Shuttle specific operator interface. Routines to support forward, echo and 
status messages specifically for the Space Shuttle were added. New attribute files were created 
to support system configuration for Johnson Space Center (JSC), Tape, and Emergency Voice 
Command Fill (EVCF) commanding. The "PSK MOD/DEMOD Interface" in figure 6 was 
replaced with the "SCM MOD/DEMOD Interface" which included new device driver software 
for the Shuttle Command Module (SCM). 


SUMMARY 

After detailed research and analysis, the NCPS was developed and implemented to provide GN 
sites with command capability for support of spacecraft operations. The modularization and 
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commonality of parts have help produced a system that can be expanded as needed. Software 
and hardware modules can be added to the NCPS as requirements to support future sites and 
spacecraft are identified. 
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FIGURE 1 . NCPS FUNCTIONAL BLOCK DIAGRAM 
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FIGURE 2. NCPS RACK ELEVATION 









FIGURE 3. FRACTIONAL FREQUENCY SYNTHESIZER 
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FIGURE 4. PMB FUNCTIONAL BLOCK DIAGRAM 

















FIGURE 5. SCM FUNCTIONAL BLOCK DIAGRAM 














Command Files Request Queue Command Pool 



369 


FIGURE 6. NCPS DATA FLOW DIAGRAM 
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